Interactive CRUD + S3 Student Picture (v2 · API Creates Picture Key)

1. UI Layer

Browser / SPA where students and staff interact.

Student form Name, course, email → JSON to API.

Picture selector <input type="file"> + client preview.

Presigned PUT Browser uploads directly to S3 using signed URL.

2. API Layer (EC2)

Node.js/Express API with IAM role for S3 & RDS.

CRUD endpoints /v2/students manage metadata in RDS.

API creates picture_key On POST /v2/students, generates students/{id}.jpg and saves to DB.

Presigned URL generator Uses S3 SDK for putObject & getObject.

3. Storage Layer

S3 for binaries, RDS for metadata & relationships.

Amazon S3 (private) Keys like students/{id}.jpg, bucket blocks public access.

Amazon RDS students table stores name, email, course, picture_key.

Read replica Optional replica for heavy reads (e.g., list all students).

End-to-end picture flow – API creates picture_key

Student Picture Flow – Step by Step

UI – Browser

1. Create student (no file yet) POST /v2/students with JSON only.

2. API returns picture_key Response includes picture_key: "students/{id}.jpg".

3. Request upload URL GET /v2/students/:id/picture-upload-url.

4. PUT to S3 Browser uploads JPEG to S3 using presigned URL.

5. View from S3 GET /v2/students/:id/picture-view-url → ``.

API – EC2

On create Insert student row → get id → build picture_key → update row.

Upload URL Reads picture_key from RDS, generates putObject presigned URL.

View URL Reads picture_key from RDS, generates getObject presigned URL.

Delete picture (optional) DELETE picture API: removes object from S3 + clears picture_key in RDS.

S3 + RDS

RDS students table Stores picture_key as pointer to S3.

S3 key pattern students/{student_id}.jpg or students/{student_id}_{timestamp}.jpg.

Security Private bucket, IAM role with least privilege, short-lived presigned URLs.

REST API Design – CRUD + S3 (API creates picture_key)

On POST /v2/students, the API creates the student row and immediately generates a default picture_key (e.g. students/{id}.jpg) and stores it in RDS.

Method	Endpoint	Purpose	RDS behaviour	S3 behaviour
POST	`/v2/students`	Create new student (metadata only).	Insert row → get `student_id` → generate `picture_key = "students/{id}.jpg"` → update row.	None yet (no file uploaded).
GET	`/v2/students`	List all students.	Read from RDS (can use read replica).	None.
GET	`/v2/students/:id`	Get one student.	Read from RDS.	None.
PUT	`/v2/students/:id`	Update metadata.	Update RDS row (name, course, email).	None.
DELETE	`/v2/students/:id`	Delete student.	Delete row from RDS.	Option: delete object at stored `picture_key`.
GET	`/v2/students/:id/picture-upload-url`	Get presigned URL to upload picture.	Read existing `picture_key` from RDS.	Generate `putObject` URL for that key.
GET	`/v2/students/:id/picture-view-url`	Get presigned URL to view picture.	Read existing `picture_key` from RDS.	Generate `getObject` URL for that key.
DELETE	`/v2/students/:id/picture` (optional)	Delete picture only.	Set `picture_key = NULL` in RDS.	Calls `deleteObject` on S3.

Node.js API – create student + picture_key

// POST /v2/students
app.post('/v2/students', async (req, res) => {
  try {
    const { name, course, email } = req.body;

    // 1) Insert student metadata
    const [result] = await pool.query(
      'INSERT INTO students (name, course, email) VALUES (?, ?, ?)',
      [name, course, email]
    );

    const studentId = result.insertId;

    // 2) API auto-creates picture_key
    const pictureKey = `students/${studentId}.jpg`;

    // 3) Save picture_key in DB
    await pool.query(
      'UPDATE students SET picture_key = ? WHERE student_id = ?',
      [pictureKey, studentId]
    );

    // 4) Return metadata + picture_key
    res.status(201).json({
      student_id: studentId,
      name,
      course,
      email,
      picture_key: pictureKey
    });
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Failed to create student' });
  }
});

Presigned upload & view – using stored picture_key

// GET /v2/students/:id/picture-upload-url
app.get('/v2/students/:id/picture-upload-url', async (req, res) => {
  try {
    const { id } = req.params;

    const [rows] = await pool.query(
      'SELECT picture_key FROM students WHERE student_id = ?',
      [id]
    );
    if (!rows.length) {
      return res.status(404).json({ error: 'Student not found' });
    }
    const key = rows[0].picture_key;
    if (!key) {
      return res.status(400).json({ error: 'No picture_key defined' });
    }

    const uploadUrl = s3.getSignedUrl('putObject', {
      Bucket: BUCKET,
      Key: key,
      Expires: 300,
      ContentType: 'image/jpeg'
    });

    res.json({ upload_url: uploadUrl, key });
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Failed to create upload URL' });
  }
});

// GET /v2/students/:id/picture-view-url
app.get('/v2/students/:id/picture-view-url', async (req, res) => {
  try {
    const { id } = req.params;

    const [rows] = await pool.query(
      'SELECT picture_key FROM students WHERE student_id = ?',
      [id]
    );
    if (!rows.length || !rows[0].picture_key) {
      return res.status(404).json({ error: 'No picture uploaded' });
    }

    const viewUrl = s3.getSignedUrl('getObject', {
      Bucket: BUCKET,
      Key: rows[0].picture_key,
      Expires: 300
    });

    res.json({ view_url: viewUrl });
  } catch (err) {
    console.error(err);
    res.status(500).json({ error: 'Failed to create view URL' });
  }
});

Student Profile · UI Mockup

S3 Picture · API creates picture_key

Student Name

Course

Student Picture (stored in S3)

Flow guide:
• API auto-creates picture_key when student is created.
• Browser never sends image file to RDS.
• Browser uploads picture directly to S3 using presigned URL.
• UI displays picture via presigned GET URL.

Exam / CA talking points

Why store picture_key in DB? S3 stores the file, but the system needs a stable pointer. RDS holds the object key so the API can generate presigned URLs, delete pictures and join metadata easily.

Why API creates picture_key? Keeps the naming convention centralised, avoids the UI guessing keys. It also allows simple queries such as “find all students who already have picture_key set.”

Security note Bucket stays private, no public URLs. Presigned URLs are time-limited and scoped to a single object. IAM role on EC2 is least-privilege.

MCQ Trainer – CRUD + S3 (API creates picture_key)

Score: – / 10

S3 Lifecycle Policy

S3 lifecycle rules automate transitions and clean-up for student picture objects.

Transition to Standard-IAAfter 30 days

Transition to Glacier Deep ArchiveAfter 180 days

Expire objectsAfter 365 days (optional)

{
  "Rules": [
    {
      "ID": "student-picture-lifecycle",
      "Prefix": "students/",
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 365 }
    }
  ]
}

Glacier & Deep Archive Behaviour

Object moves to Glacier / Deep Archive When an S3 object transitions to GLACIER or DEEP_ARCHIVE, it cannot be read instantly. Presigned GET URLs and getObject() will return InvalidObjectState until the object is restored.

Do we need to change the API code? No. Your API code remains the same. The picture_key stays valid and does not change. Only the object's storage class changes internally in S3.

Why API GET fails for Glacier objects Because Glacier is offline storage — data must be restored before access. The API will receive InvalidObjectState during this time.

Optional: Add restore endpoint Only if your application needs to restore pictures on demand.

POST /v2/students/:id/picture-restore

// Example Node.js
s3.restoreObject({
  Bucket: BUCKET,
  Key: pictureKey,
  RestoreRequest: {
    Days: 7,
    GlacierJobParameters: { Tier: "Standard" }
  }
});

Glacier Restore Timing • Expedited: 1–5 minutes (if available)
• Standard: 3–5 hours
• Bulk: 5–12 hours
During this period, presigned GET still fails.

Best practice for student pictures Do NOT transition student profile pictures to Glacier unless they are archived alumni or inactive accounts. Use Standard-IA for cost savings but keep pictures instantly retrievable.